应用的日志分析、对比以及实践
前言
随着业务量的增长，服务器的增长，同时应用日志的数量也是呈现几何的速度增长。大部分人的认为日志数据对业务来说只是开发人员排除故障的依据，除此以外对业务而言是没有任何的意义的。我相信，对很多人的认知来说日志也就那么点的作用。不可或缺，但是也是很鸡肋。需要它的时候，迫不及待，不需要它的时候弃之如敝履。
作用
- 常见作用: 排问题，查日志（
点）
- 日志记录代码的执行记录，记录异常信息，排查代码的隐藏bug
- 记录业务逻辑，查询业务上的问题或者追踪相关信息
- 非常见作用: 数据分析（
面）
- 根据错误日志的错误处，统计错误率，针对性的对代码进行优化
- 根据时间轨迹，可以统计出业务的集中时间和接口调用次数等统计
- 统计用户业务轨迹
- …….更多的数据价值待挖掘，比如从日志中统计用户类型、用户访问习惯、用户停留时间、用户的等待时间等等各个方面，针对性的优化应用，提升用户的访问体验。
变化
到目前为止，参照我们系统( 某上市互联网保险中介 )应用，就日志而言，我们经历了以下几个时间段的变化，也经历很多方面的尝试。就目前我们的应用日志系统经历了以下的变化:
原生时代
描述: 早期的终端原生时代，由于业务和服务器的规模不是很大，针对应用的日志并没有做相应的的处理和优化。都只是应用容器本身的日志处理，开发需要看日志就去对应的服务器上看相应的日志。比如tomcat下自由log4j下的catalina.out等等。
特点: 方便，对开发相对友好，因为在自己的PC开发环境中，开发更加习惯在文本或者终端查看日志。但是在linux平台下查看应用日志，需要具体的一定的Linux日志命令的相关基础知识，如tail、awk等
nfs共享
描述: 随着业务规模的增加，服务器的数量增长，应用日志的数量也在增加。通常一个业务还有7到8个集群节点的日志，这时候如果还是采用的原生时代的日志查看方式会显得的很费力。查一个日志可能要登陆10多个终端在日志当中去排除问题。所以在这时候的我们考虑将日志归集到一起，这样就避免了开多个服务器去看日志的问题。
特点: 相对于原生时代来说，其实没有发生了什么变化。只是不需要登陆多个服务器，只登陆一台服务器就能看到所有服务器的日志。
splunk
描述: 这是一款商业的日志系统，集合日志收集、处理、分析等一体的日志解决方案。当日志文件超过500M就要收费的。但就它的功能而言，各方面的表现都非常不错的。web可视化，日志异常，资源占用率等很不错。唯一的是，基于当时的业务情况并不适合在日志收集去投入额外的资产支出，所以后续就放弃了。
特点: 采用CS结构，各方面的都比较优秀。
log.io日志系统
描述: 这是一款开源的实时日志系统，它只实时显示日志，并不对日志做存储。也是C/S结构，采用node的语言编写而成。
特点: 采用CS结构，小巧易于使用。
elk
描述: 这是一款开源的集中式日志系统，也是目前很多互联网公司主推的开源日志系统。ELK 其实并不是一款软件，而是一整套解决方案，是三个软件产品的首字母缩写，Elasticsearch，Logstash 和 Kibana。从日志收集、聚合、全文搜索、展现等拥有一套完整的解决方案。社区和文档也比较完善，可以进行自定义二次开发。
特点: 采用CS结构，功能强大。
flume
描述: 这是一款开源的日志收集的解决方案，并不对日志进行分析，flume是一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统。通过与kafka等结合做日志解决方案。
特点: 采用CS结构，可扩展性强，存储丰富比如HDFS.自研平台
描述: 综合业务等个方面的特点自定义的开发日志系统。
特点: 自主性强、适合业务的可持续性扩展。
使用对比
调研
前置环境:
服务器数量: 40 +
应用容器类型: tomcat/resin/php等
日志大小: 500M > size < 5G
环境: 集群环境
需求调研
- 方便开发人员查询日志，排除故障
- 不占用系统资源，一般日志系统采用C/S结构，客户端的资源占用率必须保障在3%以下
- 扩展性强，易于进行二次开发
总结
目前在行业内日志处理方案，有开源的，也有商业级别，也可以自行开发。至于你要选择什么解决方案，完全要依赖于你的业务需求和环境，如果你有更加高的要求的日志要求，且对费用没什么担心，商业版本的日志解决方案无疑是最佳的解决方案。如果你的资产投入有限，或者想自定义日志的系统，开源或者自研也是可以的。选择最合适业务，然后去调研、测试，来最贴近你的业务需求。
